Location tagging method for packet based signalling

ABSTRACT

Location information is tagged in a packet based network. SIP signaling messages are used to initiate a communication session between at least two end user devices in a packet based telecommunications network. The communication session is routed through various intermediate network elements of the packet based network. The intermediate network elements tag the signaling messages with information indicating their geographic location or otherwise provide such location information. In response to the signaling messages and preferably before the communication session is established, the location information indicating the location of the intermediate network elements in the routing of the communication session between the end user devices is made available. An end user device or apparatus may receive the location information and provide a user display indicating the routing and status of the communication session being initiated.

FIELD OF THE INVENTION

The present invention relates generally to telecommunications. Moreparticularly, the invention relates to the signaling procedures forcommunications sessions in packet based telecommunications networks.

BACKGROUND

A packet based telecommunications network is a geographicallydistributed collection of nodes interconnected by communication linksand segments for providing communication sessions (e.g., phone calls,multimedia and other data) between end nodes. The end nodes typicallyconsist of user devices, such as personal computers, cell phones,personal digital assistants (PDAs), and the like. Many types of packetbased telecommunications networks are available, with the types rangingfrom local area networks (LANs) to wide area networks (WANs). LANstypically connect nodes over dedicated private communication linkslocated in the same general physical location, such as a building orcampus. WANs, on the other hand, typically connect large numbers ofgeographically dispersed nodes over long-distance communication links,such as common carrier telephone lines. Examples of WANs are 3GPP and3GPP2 compliant wireless networks, and Long Term Evolution (LTE)wireless networks. The nodes of packet based networks typically signaleach other over the network by exchanging discrete frames or packetsaccording to predefined protocols, such as the Transmission ControlProtocol/Internet Protocol (TCP/IP). The Internet itself connectsvarious networks throughout the world, providing global communicationbetween nodes in the various networks.

A packet based telecommunications network may comprise a series ofintermediate nodes (e.g., routers) that are configured to carrycommunications through the network to the end nodes. Routers are oftenconfigured to “route” data, such as packets, between various nodes inthe network. Routing is typically performed at layer-3 (L3), which isthe network layer of the Open Systems Interconnection (OSI) networkmodel. Routers often maintain forwarding databases (FDBs), which aretypically configured to hold routing information including L3 addressesand interface information that the router uses to determine where data(e.g., data packets) are to be forwarded in order to reach theirdestination. For example, a router may have a routing databasecontaining one or more entries wherein each entry contains an L3destination address of a destination node and interface informationabout an interface on the router through which the destination node maybe reached. A data packet containing a destination address that matchesa destination address of an entry in the routing table is forwarded bythe router to the interface specified by the matching entry for transferto the destination node.

The end nodes of a communication session are known and defined as partof the communication session. Although the physical (geographical)locations of the end nodes may initially be unknown, some IP basedcommunication networks enable an end node to learn its geographiclocation from a server. In a wireless network, the server may employtriangulation or other methods to determine the end node's geographiclocation. The end node may then learn its location by issuing a requestto the server to which the server responds with the geographic location.See, for example, European Patent Application No. 1 477 302 entitled“Integrating Geographical Contextual Information Into Mobile EnterpriseApplication”, or IETF RFC 3825, by J. Polk et al., entitled “DynamicHost Configuration Protocol Option for Coordinate-based LocationConfiguration Information”. Numerous efforts to obtain the geographicallocation of end nodes is known for purposes of 9-1-1 and other emergencyservices. See, for example, draft IETF document entitled “Emergency CallServices for SIP-based Internet Telephony” by Henning Schulzrine, datedMar. 25, 2001.

The packets for communications sessions are often routed through variousnetworks and intermediate network elements. In packet based networks,each session (and even each message) may be transferred via a differentroute. For example, a call made from Australia to Finland may go throughUK and Sweden while a similar call made a minute later may take atotally different route. In an ad-hoc network, such as a mesh network,this is further complicated since a user device may operate as either anend node or an intermediate node.

The physical (geographical) route of intermediate network elementsthrough which the packets travel is not known in advance for severalreasons. A router may execute one or more routing protocols that enablethe router to route packets and exchange routing information with otherrouters in the network. The routers often use this information toconfigure (e.g., compute) their FDBs. The routing protocols may includedistance-vector protocols, such as the Routing Information Protocol(RIP), or link-state protocols, such as theIntermediate-System-to-Intermediate-System (IS-IS) protocol and the OpenShortest Path First (OSPF) protocol.

Since the routing is not known in advance, the intermediate networkelements are not known and may be signaling elements (such as a CallState Control Function (CSCF) in a 3GPP network), media gateways, oreven user devices in an ad-hoc network. It would be useful to obtaininformation about the intermediate network elements. Furthermore, itwill be useful to know the geographical location of the intermediatenodes routing a communication session. The intermediate nodes may be indifferent countries, even when both the end nodes are in the samecountry.

The reasons for this may be various. For example, an organization maywant to route traffic via a foreign country for tax purposes (e.g. toavoid tax on local calls), or an operator's network infrastructure (e.g.operator's network elements) may be located in different countries.Currently, it is difficult to know reliably what network elements havebeen involved in a communication session and the countries in whichthose network elements are located.

This creates tax problems and law enforcement related problems.Different taxes may apply to communications based on the countriesinvolved. Currently, it is very difficult to get and document thisinformation reliably. Certain law enforcement actions, such aswiretapping, vary by jurisdiction. For example, different laws may applyto foreign communications (or communications that involve a foreigncountry). It is also difficult to know reliably if foreign countrieswere involved in the call (e.g. only the operator may be known). Thereare various prior attempts related to these concerns, but none of themare sufficient. For country boundary information, the operator identityprovided by an network operator was typically enough to make theassumption that the home country of that operator was involved(similarly, visiting network information may have been available). Fortax purposes, it was usually enough to trust the word of the operator.

For diagnostic purposes, there may be a natural disaster and/or humanconflict strife affecting a region, city or neighborhood. It would beuseful to know what effect this is having on communications,particularly geographic routing on a per session and/or per packetbasis. Real-time diagnostic maps in which network elements arerepresented by their IP address or other identity information (andfunction name, such as CSCF) are not sufficient. Ad hoc networks couldalso benefit from diagnostic monitoring of routing as it is an easy wayto find out which devices are willing and able to route communicationstraffic.

A network operator may maintain a separate database, which includes thephysical location of network elements, but it is not previously knownhow to utilize that information in real-time or near real-time on a persession or a per packet basis. But a network element can be physicallymoved, and the database entry corresponding to that network element maynot be updated properly when the location changes.

It also might be useful and entertaining for end users to know thegeographical route for packet traffic of their communication sessions.Currently, when an end user is making a call, sending a message, orinitiating another kind of communications session, the user devicetypically is not very informative and just displays “calling . . . ” or“in progress” while the communications session is set up. While U.S.Pat. No. 6,278,454 does discuss a user interface (UI) that provides callprogress information, it does not provide geographic routing or locationinformation.

In light of the shortcomings described above, it would be advantageousto develop methods and network elements which enable tagging of thelocation of intermediate nodes for a communications session in a packetbased network. It would be preferable to have methods and apparatus thatpermit a device, such as an end user device, to utilize the taggedlocation information for various purposes, such as displaying therouting and progress of the communication session.

BRIEF SUMMARY

The preferred embodiments of the invention involve methods and networkelements in which location information and other advanced information ofthe network elements involved in the routing is added into the signalingfor each communication session or message. The location information isuseful for diagnostic purposes, law enforcement and tax purposes. Theadditional information may include, for example, host platform, CPU andmemory information and even weather information around each networkelement (this may be useful in some games, and it may be entertainingfor end-user).

Each network element along the route either adds its own information tothe packet, or sends the information to a Network Element InformationServer. The packet may be a SIP packet and the information may be addedin a distinct SIP extension header. The geographical locationinformation tagging can be done on a per packet or per session basis.

The end-user may be informed, in real-time or almost in real-time, by auser interface in the end user's device about the progress of thesession setup (or message sending) with regard to the physical locationof the network elements and the destination party involved, in additionto other information. The information may be shown to the end user intext, animation or graphical form. For example, the end user device mayshow a map and then highlight a location (e.g. “Detroit, Mich.”) whenthe network element in that location has been involved, and draw aprogressing line between the locations of the network elements.

BRIEF DESCRIPTION OF THE DRAWINGS

In association with the following detailed description of the preferredembodiments, reference will now be made to the accompanying drawings,where like numerals in different figures refer to the same element, andin which:

FIG. 1 is a block diagram of a 3GPP network having an IMS architectureand in which the preferred embodiments of the present invention may beimplemented;

FIG. 2 is a flow diagram of the prior art signaling for a SIPcommunication session in the 3GPP network of FIG. 1;

FIG. 3 is an example of a SIP INVITE message in the signaling of FIG. 2;

FIG. 4 is a block diagram of the architecture of an exemplary networkwith a Network Element Information Server;

FIG. 5 is a diagram of the architecture of an ad-hoc network(proxy-require) with a network element information extension;

FIG. 6 is an example of the prior art end user device UI during callsetup;

FIGS. 7-11 are examples of an end user device UI during call setupaccording to a preferred embodiment of the invention;

FIG. 12 is an example of an end user device UI during a call attemptaccording to another preferred embodiment of the invention;

FIG. 13 is an example of an end user device UI after a message is sentaccording to another preferred embodiment of the invention; and

FIG. 14 is an example of call history shown in a map according to apreferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred and exemplary embodiments of the present invention now will bedescribed in detail with reference to the accompanying drawings. FIG. 1shows an exemplary 3GPP wireless telecommunications network in which thepreferred embodiments related to a SIP communication session may beimplemented. It should be understood, however, that various embodimentsof the present invention can be utilized in conjunction with a varietyof other telecommunications networks and a variety of othercommunication services and features. Embodiments of the invention may beapplied in various kinds of networks, especially packet based networkssuch as PacketCable networks.

As shown in FIG. 1, and discussed above in the background section, acommunication session between two end user devices UE 1 and UE 2 in aprior art 3GPP network with an IMS architecture involves manyintermediate network nodes. Assuming each end user device is roaming,there is a visited network 100 for UE 1 and visited network 200 for UE2. Each visited network has a radio access network (RAN) 101, 201; aServing GPRS Support Node (SGSN) 102, 202; a Gateway GPRS Support Node(GGSN) 103, 203; and a Proxy Call Session Control Function (P-CSCF) 104,204. (The RAN 101, 201 is not a single network, but is instead comprisedof several network elements.) The P-CSCF 104, 204 communicaterespectively with a Serving Call Session Control Function (S-CSCF) 111,211 in Home Network 110 of UE 1 and Home Network 210 of UE 2, which inturn communicate with an Interrogating Call Session Control Function(I-CSCF) 212 in Home Network 210 of UE 2. I-CSCF 212 accesses HomeSubscriber Server 213 in Home Network 210 of UE 2 which, among otherthings, stores information on the physical location of UE 2. The actualphysical transmission or IP packet transmission between the networkelements, and other details of the network, can be derived from thepublished specifications of the Third Generation Partnership Project(3GPP) or from other sources. The preferred embodiments operate so as tobe independent of, and not limited to, any particular physical layerenvironment.

A session control and messaging protocol may be employed to establish asession (connection) that supports a call between UE 1 as the callingparty and UE 2 as the called party. An example of a session control andmessaging protocol is the Session Initiation Protocol (SIP) is describedin IETF RFC 3261 by J. Rosenberg et al., entitled “SIP: SessionInitiation Protocol”. SIP is used as a session control protocol (such asto establish and terminate a call) and a messaging protocol (such as tosend an instant message). It operates at the application layer of theOSI Network Model and is defined to establish sessions between end userdevices (e.g., SIP-based telephones) in a packet based communicationnetwork. After the session is established, typically a direct datasession is established between the handsets.

Typically, SIP messages go from the user terminal to a first networkelement, then to next network element, and finally to the destination(which may be end-user device, registration server, application serveror some other element). There is often large number of network elementsinvolved along the route. Since it is implemented at the applicationlayer, the actual physical transmission or IP packet transmission via IPlevel elements is not affected by the preferred embodiments and have noeffect on the preferred embodiments.

At the beginning of a call, a session is typically established betweenthe end user devices to support the call. Establishing a session betweenthe parties often involves (a) authenticating both parties and (b)successfully exchanging a sequence of messages between the end users andintermediate nodes in a predetermined manner. Authentication usuallyinvolves ensuring the parties have permission to establish the call. Thesequence of messages typically includes an INVITE message issued by thecalling party, which is followed by a sequence of INVITE messages fromone network node to the next, until the called party is reached, eachINVITE message being substantially immediately responded to with aTrying (“100”) message.

FIG. 2 shows such a signaling flow to establish a Session InitiationProtocol (SIP) in the IMS architecture of FIG. 1. FIG. 3 shows a sampleSIP INVITE message. The signaling in FIG. 2 includes a plurality of SIPInvite messages and 100 Trying messages as described above, as well as aquery to HSS 212 as to the location of UE 2. Although not shown in FIG.2, the SIP session is not fully established until appropriateacknowledgement (“200 OK”) messages and sent in the direction from thecalled party to the calling party, followed by acknowledgement (ACK)messages in the direction from the calling party to the called party.

FIG. 4 shows an exemplary 3GPP network architecture in which a preferredembodiment of the invention may be practiced. In addition to theconventional network elements, such as UEs and CSCFs, there is a newelement, a Network Element Information Server (NEIS) 400. NEIS 400 maybe a separate element as shown in FIG. 4, but is preferably integratedwith or into P-CSCF 114 or similar application server. UE 1 subscribes(1) to the service provided by NEIS 400 that provides locationinformation about the various network elements through which acommunication session is routed. The service subscription may be carriedout by any one of a plurality of suitable processes (such as, forexample, via web site, or by placing a specific header or content intoSIP messages). Alternatively, service subscription may happenautomatically without specific user action, e.g. based on user profile,or default policy. After successfully subscribing, when UE 1 initiates acommunication session, for example, places a call, to UE 2, therequested service is provided by NEIS 400. The service may also beprovided without NEIS 400, with the network elements support the serviceand the information being delivered directly to UE 1, instead of to NEIS400.

During the session setup, such as a call attempt (and possibly evenduring the session), UE 1 receives SIP NOTIFY messages (2) from NEIS 400which contain information about the network elements along the route ofthe communication session. The Network Element Info Server gets theinformation either directly from SIP message headers, or via reference,from servers located elsewhere in the network, where the locationinformation is stored by the intermediate network elements (3).(Alternatively, if the location information of the intermediate networkelements is not stored anywhere, NEIS 400 itself may find out thegeographical location of the intermediate elements.) The provisional SIPresponses, such as “100 Trying” sent by intermediate elements to NEIS400 or UE1, may also provide the information.

Preferably, each (SIP based) network element along the route can addadvanced information into the (SIP) packet header. The advancedinformation may include the geographical location of the networkelement, weather in that location and additional location basedinformation. It may also include information about the network elementitself, such as platform, CPU, and memory. The network element may alsoadd location information for (on behalf of) related elements (forexample, a media gateway, perhaps controlled by said network element, orHSS). It is also possible to include status information for each networkelement, such as “Completed”, “In progress”, “Failed”, “Waiting forresponse”, “Not responding”, etc).

This information (especially location information) is sometimesconsidered confidential. Preferably, the granularity of the informationprovided is determined by the owner of the network element (e.g.operator). For example, it is possible to use only city or state levelinformation (instead of GPS co-ordinates). It is also possible toprovide only generic or virtual information (“e.g. T-Mobile serverDragon”). Yet, some network operators may want to provide more detailedinformation as a way to differentiate themselves (it is also possiblethat law enforcement and/or standardization may require certaininformation anyway). It is also possible to provide different levels ofauthentication. For example, law enforcement and friendly networkoperators and perhaps premium users can access more detailedinformation, while basic end-users get only less detailed information).

Preferably, each network element along the route adds its owninformation into the packet. The granularity and access rights for theadded information are decided by the network element. Either, allsubsequent network elements along the route may access the information(if authentication allows it), or only the end user device or the lastnetwork element before the end user device (for example, CSCF, NEIS 400)can access the information and decide if anything is sent to the enduser device. The last network element before the end user device (forexample, CSCF) may provide the network element information only topremium end users that have subscribed to the service. It is alsopossible that the CSCF or NEIS 400 aggregates the information about allnetwork elements along the route and sends only a summary of the routeto the end user. It is further possible that the information can be sentelsewhere, such as to law enforcement or to the called party, inaddition to the calling party.

IETF RFC 3455 by M. Garcia-Martin et al, entitled “Private Header(P-Header) Extensions to the Session Initiation Protocol (SIP) for the3rd-Generation Partnership Project (3GPP)”, January 2003 describes Pheaders for SIP, although it does not describe how to add advancednetwork element information into packets or sessions. In the preferredembodiments, information is added to SIP packets so that every time anetwork element adds information, it adds a new P-Network-Element-InfoSIP header. (It is not possible to add information into SIP message bodyby proxy. Only headers can be added. However, the intermediate networkelement may add to information into the message body of provisionalmessages which it initiates, such as “100 Trying”, and sent those to theNEIS 400 or UE1.) The header may contain either the information itself,or preferably, it may contain a reference to where the information isstored (for example, a web address or a SIP event package, to beaccessed via SIP SUBSCRIBE/NOTIFY). The accessing may occur in themanner indicated in the Internet Draft entitled “Location Conveyance forthe Session Initiation Protocol” by James Polk et al, Jul. 9, 2007.However, this document assumes that only the end-point location iscarried in SIP. In the preferred embodiments of the invention, thelocation of several network entities along the route can be added, andcan be optimally reported to the end-user device.

An example SIP header field, as added by an intermediate network elementin the preferred embodiments, might look like this:

-   -   P-Network-Element-Info:        <sips:3sdefrhy244@resources.operator.com>;        inserted-by.cscf1.example.com; element=cscf1.example.com;        role=CSCF

For this example SIP header field, the recipient may use SIP SUBSCRIBE(sent to sips:3sdefrhy244@resources.operator.com) and receive a detailedlist of information in, for example, XML format.

It is also possible that the header itself lists the added information.For example, location information could be represented with longitude,latitude and altitude like this:

P-Network-Element-Info: location=GPOS, −31.6482, 134.8652, 10.1;element=cscf1.example.com; role=CSCFThis alternative is faster and simpler, but is otherwise a more limitedway of providing the location information.

P-CSCF 114 or NEIS 400 may remove the headers from the messages beforethey are sent to UE1. Alternatively, P-CSCF 114 may leave the headers inplace and let UE 1 decide what to do with the information. For example,UE 1 may do nothing or may get information about some or all of thenetwork elements.

In an alternative embodiment, the intermediate network elements may addlocation information into another message that it initiates, preferablya message that it initiates as part of the communication session setup,and send those to NEIS 400 or UE 1. Even in the SIP environment, thelocation information may be added to provisional messages that itinitiates, such as the “100 Trying” messages, rather than the SIPpackets. This has the advantage that location information can be addedinto the message body of those provisional messages, whereas locationinformation cannot be added into the message body of SIP packets.

NEIS 400 may store all of the information in a database. The locationinformation may be stored permanently (in a bulk storage medium such asa hard drive) or temporarily (in memory). The term “store” when used inthis application includes both permanent and temporary storage. It thencontrols the access of end-users, network operator personnel and outsideentities (e.g. law enforcement) to the database to obtain thegeographical location and route taken on a per session or per packetbasis, as well as other relevant network element information.

FIG. 5 illustrates an ad-hoc network architecture in which anotherpreferred embodiment of the invention may be implemented. In this ad-hocnetwork, each network node, UE 2, UE 3, UE 4, UE 5 and UE 6, forwards amessage from UE 1 and hopefully, the message eventually gets deliveredto the Radio Access Network (RAN) and then to the core network. Thesender (UE 1) adds a header, such as a “Proxy-require” header indicatingthat every network element along the route must support the networkelement information feature. It is also possible to use other headers,such as “Supported: network-element-info”, indicating that UE 1 supportsthe route tagging of location information and that it is possible (butnot mandatory) to add such location information.

These preferred embodiments thus provide geographical locationinformation and other advanced information about the network elementsalong the route, preferably using SIP. The information may be added ateach network element automatically without any specific request, or itmay depend on each message. For example, the message may contain aspecific SIP header triggering the feature, or utilize a SIP SUBSCRIBE,or a web based request may have been received for the service.

The additional information is added by the network elements along theroute. The new information is added to SIP headers either directly (sothe header contains the information), or by a reference so that the SIPheaders contain information on how to access the location informationfor a given network element. Eventually, the end-user device gets theinformation (e.g. SIP message with 6 P-network-element-info headers) orit may access the information via a reference. Alternatively, the lastnetwork element before the originating device (e.g. P-CSCF) may removethe extra information (P-network-element-info headers) and provide theinformation—perhaps in aggregated form—to the end user device via somemean, such as using SIP SUBSCRIBE/NOTIFY mechanism, SIP MESSAGE, web, orplacing the information into SIP headers (e.g. one extra headercontaining a link or reference pointing to the said server). As aresult, the geographical location information (and other informationrelated to the intermediate elements for a given session or packetroute) is available in real-time (e.g. during the call attempt), or inalmost real-time, or afterwards. The network element info server storesthe information and can provide statistics, summaries and aggregatedinformation to the end user device and to other entities. It is alsopossible to use authentication and access levels to ensure that onlycertain parties can access the information. Also, it is possible toprovide only coarse-granular information, (e.g. city level informationas opposed to GPS co-ordinates). Network Element Info Server may alsomodify the information (e.g. do language translations, convert data intoanother format, provide a visualized map, provide distance betweenelements etc). It is also possible that network elements provide similarinformation about other elements (e.g. media servers, GGSN, HSS or RANelements).

Although not addressed in detail, it is understood that the networkelements have a construction that is known to those of ordinary skill inthe art. In particular, there is a processing element, memory, and othercomponents of the network elements that are operable to execute asoftware program which, when executed, causes the network element tocarry out the operations and functions described in this application.This software program may be provided as software program product whichis installed in the network element by downloading the software programor by reading the software program from a tangible recording mediumreadable by the network element.

In addition to the memory, the processing element of these networkelements may also be connected to at least one interface or other meansfor transmitting and/or receiving data or the like. In this regard, theinterface(s) can include at least one communication interface or othermeans for transmitting and/or receiving data. The communicationinterface may communicate with and receive data from external devices,using any known communication technique, whether wired or wireless,including but not limited to serial, universal serial bus (USB),Ethernet, Bluetooth, wireless Ethernet (i.e., WiFi), cellular, infrared,and general packet radio service (GPRS). Upon receipt of data, thenetwork element may transmit the data to other network elements via thecommunication interface. A communication interface may also enable thenetwork elements to communicate with a public network such as theInternet or any other suitable communication network.

The processing element may also be connected to at least one userinterface that may include a display element and/or a user inputelement. The user input element, in turn, may comprise any of a numberof devices allowing the client device to receive data and/or commandsfrom a user, such as a keypad, a touch display, a joystick or otherinput device.

FIG. 6 shows a typical prior art method of showing session setupinformation to a user. It just shows the text “calling” to the end userinitiating a call as the calling party. This is prior art method is notvery informative.

FIGS. 7-12 show preferred embodiments with richer user interfaces andhow location and status information can be shown in the UI. FIG. 7 showsthat, once the user has initiated the call attempt (e.g. by pressingCall button), the user interface shows, in real-time or near real-timethe geographical information about the setup progress. In this example,it shows the location names for the two places where the session setuphas been processed so far. This preferred embodiment preferably showsall locations, possibly with the status information (such as“Completed”, “In progress”, etc) for each location.

FIG. 8 shows another preferred embodiment in which the session progress(with regard to location status) is shown on a graphical map 800. It maybe 2D map or 3D map. It may highlight the locations where sessionprocessing is done, such as by using a blinking icon 810 to highlightthe location where the session is currently being processed.Alternatively, it may highlight more than one location or a line betweenlocations.

FIG. 9 shows a preferred embodiment in which the route is drawn, therebycreating a graphical presentation of the session progress (or messagesending). The route may be drawn with or without a map.

FIG. 10 shows a preferred embodiment in which there is an animation 1000showing the progress of the communication session. It may be a Flashbased animation or some other type of animation. It shows the locationof network elements where the processing happens, and possibly thestatus for each element. It may also show pictures related to thepersons involved in the call, or some other pictures (such as thenetwork elements involved or nearby city pictures or landmarks).

FIG. 11 shows a preferred embodiment where additional information isincluded in the user interface. The function for each location may alsobe revealed, for example, authentication, resource reservation, waitingfor response, etc. It may also show the name of the elements involved,such as real name (CSCF), product name, or some other name (e.g.,Signaling Server, Authentication Server, etc). It is also possible

Progress may also be shown (for example, as a percentage—25%, estimatedtime left—2 seconds etc). Additional information shown may be how manymiles the signaling traverses or how many countries or states it wentthrough.

FIG. 12 shows an example of how weather related information can be shownwith icons, along with other information. The weather information may beshown in text, graphics, animation or icons. It may show weather in thelocations where the session messages are processed.

FIG. 13 shows another preferred embodiment for message sending, in whicha richer user interface is used and location and status information canbe shown in the UI. For example, an instant message or SMS may be sentand similar geographical status information as to FIGS. 7-12 above maybe shown to the user. It may also display the location of a routingproblem (e.g. no response from messaging server in Dallas), and theoperator name for each location.

FIG. 14 shows an example of a call log with visualized information. Itincludes a map and the routings for each of the calls made from thedevice. It can show the routes on a per session or message basis, or onecombined version in which all calls are shown.

The abovementioned examples can be combined in anyway possible andobvious variations can be made to the invention. It is also possible toshow the location information for the caller and the callee. Theembodiments may be implemented in a variety of different end userdevices, such as laptop computers, mobile phones, desktop phones, andother call and messaging devices.

Frequently, there may be several network elements in the same city orother location. They may all be shown or only the one location (coveringall network elements in that location) may be shown. This decision, andother decisions on how detailed of location and status informationshould be displayed, may be made by the network operator and/or by theend user device.

If the real location information (e.g. for the called party) is notavailable, it is possible to show the home area or show that theinformation is private. In case operators or other parties do not wantto reveal location information, it can be shown as private, or then itis possible to estimate the location. For example, it is possible toshow the destination (home area or real location for the destinationparty, and caller's own location) and then estimate the route e.g. byshowing numerical progress or even guess the locations based on theinformation available via other sources.

This invention can also be applied in ad-hoc network environment wherethe network elements (e.g. other end user devices) are moving so theirlocations can be updated on display. This invention can also be appliedin multi-party conferences. For example, the path to each participantcan be shown (if available), along with other status information. It isalso possible to integrate this information with conference setupapplication and user interface. It is also possible to show the reallocations for each conference participant in the conference application.

This invention can also be applied to registrations (e.g. SIPregistrations in 3GPP networks). For example, when the phone is turnedon, registration messages are sent to the network (possibly via visitingnetwork, through intermediate network to the home network) and thegeographical information about the route (with related statusinformation) can be presented on the user interface.

Geographical location information and status information can be combinedwith other information, such as time information. For example, the UImay show that the processing is now in Detroit (or between Detroit andPalo Alto), so far the processing has lasted 4.5 seconds, the estimatedtime left is 1.4 seconds, and the time spent processing in Detroit was2.5 seconds.

Geographical status information can be shown in session terminationphase (for example, when ending the session). It can alternatively beshown during the session itself (ie signalling messages or user messagesmay be sent during the session).

It is also possible to show advanced status information for eachlocation. For example, if a city has a drop rate of 20% or if there is amassive blackout. Operator information can also be shown for eachlocation.

The geographical information may be detailed (for example, GPSco-ordinates), or may be merely the name of the city, county, state orcountry in which the network element is located. The geographicalinformation is preferably provided by the network operator, but it mayalso be estimated, in case the actual information is not available inreal-time, or for some other reason.

The implementation of the end user service depends greatly on the enduser device. Most particularly, the implementation will depend on theoperating system (such as Symbian) and existing UI (such as Series 60)of the end user device. It is preferable that the end user service beimplemented through a computer program or other software recorded on atangible medium. The end user service may also be implemented throughfirmware. Preferably, the end user service can be implemented so that itmay be made easily available as a new service to the end user in acommercial wireless network environment involving a network operator.

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseinventions pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the inventions are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1-24. (canceled)
 25. A network element in a packet based network, thenetwork element comprising: a communication interface, saidcommunication interface being adapted to communicate in said packetbased network; a processing element; and a memory, said memory storingprogram instructions executable by said processing element to cause saidnetwork element to perform a function, said communication interfacebeing configured to receive a signaling message, said signaling messagebeing related to the initiation of a communication session between atleast two end user devices in said packet based network being routedthrough said network element, and said processing element, in responseto said signaling message, executing program instructions causing saidnetwork element to provide location information indicating the locationof said network element in the routing of said communication sessionbetween said at least two end user devices.
 26. The network elementaccording to claim 25, wherein the location information is inserted intothe header of said signaling message.
 27. The network element accordingto claim 26, wherein the signaling message is a SIP signaling message,and the location information is provided using an extension header addedto said SIP signaling message.
 28. The network element of claim 27,wherein the extension header includes the location information or areference to the location information.
 29. The network element of claim27, wherein the location information is provided to a network elementinformation server or to the end-user device.
 30. The network element ofclaim 25, further comprising providing said location informationdepending on the presence of a request for said location information insaid signaling message.
 31. The network element of claim 25, wherein thelocation information further comprises weather information related tothe location of at least one of said network elements associated withthe routing of said communication session between said at least two enduser devices.
 32. The network element of claim 25, wherein the locationinformation further comprises host platform information related to atleast one of said network elements associated with the routing of saidcommunication session between said at least two end user devices. 33.The network element of claim 25, wherein the location information isconfigured to be provided to a network element information server or toat least one of the said end-user devices.
 34. A user apparatus, saiduser apparatus comprising: a communication interface, said communicationinterface adapted to communicate in a packet based network; a processingelement; and a memory, said memory storing program instructionsexecutable by said processing element to cause said user apparatus toprovide a user interface, said communication interface being configuredto initiate or receive signaling messages, said signaling messages beingrelated to the initiation of a communication session between said userapparatus and another network element, and location information relatedto at least the location of intermediate network elements in the routingof said communication session between said user apparatus and anothernetwork element, said processing element, in response to said signalingmessages and said location information, executing program instructionscausing said user apparatus to provide an indication of said locationinformation related to at least the location of one or more intermediatenetwork elements in the routing of said communication session betweensaid user apparatus and another network element.
 35. The user apparatusaccording to claim 34, wherein the signaling messages are SIP signalingmessages.
 36. The user apparatus according to claim 34, wherein the userapparatus displays the routing of said communication session inreal-time or near real-time while the communication session is being setup or after the communication session has been set up.
 37. The userapparatus according to claim 34, wherein the location informationincludes status information relating to the status of the routing andthe user apparatus displays said status information in real-time or nearreal-time while the communication session is being set up or after thecommunication session has been set up.
 38. A network element informationserver in a packet based network, the server comprising: a communicationinterface, said communication interface being adapted to communicate insaid packet based network; a processing element; and a memory, saidmemory configured to store program instructions executable by saidnetwork element information server to cause said network elementinformation server to provide location information for a plurality ofnetwork elements in said packet based network, said communicationinterface being configured to receive signaling messages from saidplurality of network elements, said signaling messages being related tothe initiation of a communication session between at least two end userdevices in said packet based network being routed through said pluralityof network elements and containing location information related to saidplurality of network element, and said processing element executingprogram instructions causing said network element to store locationinformation indicating the location of at least one network element inthe routing of said communication session between said at least two enduser devices, and configured to provide said location information inreal-time or near real-time while the communication session is being setup or after the communication session has been set up
 39. A networkelement information server according to claim 38, wherein the signalingmessages are SIP signaling messages.
 40. A method of tagging locationinformation in a packet based network comprising: receiving a signalingmessage, said signaling message being related to the initiation of acommunication session between at least two end user devices in saidpacket based telecommunications network and being routed throughintermediate network elements of said packet based network; and inresponse to the signaling message, providing location informationindicating the location of at least one intermediate network element inthe routing of said communication session between said at least two enduser devices.
 41. The method of claim 40, wherein the locationinformation is inserted into the header of said signaling message. 42.The method of claim 41, wherein the signaling message is a SIP signalingmessage, and the location information is provided using an extensionheader added to said SIP signaling message.
 43. The method of claim 42,wherein the extension header includes the location information.
 44. Themethod of claim 42, wherein the extension header includes a reference tothe location information.